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(54) TiUe: A DATA PROCESSING SYSTEM FOR USE IN COMMUNICATIONS PRICING AND CHARGING EQUIPMENT AND A 
PRODUCTION PROCESS THEREFOR 

(57) Abstract 

It is impOTtant, as the communications environment grows 
increasingly complex, that it is possible to convert chargeable events 
imo billable values in a flexible manner. In particular, it is important 
that the pricing and charging arrangements available to network 
operators or service providers can take account of factors such as 
taxes which affect the billable value and which may be put in place 
in many different ways and at variable times in relation to data 
processing exercises which need to be carried out. A system is 
tfierefoie provided which can be used in generating bills by applying 
modifying factors which can be changed or added to in a relatively 
easy manner. A preferred version of the invention provides an 
objea-oriented front end for a legacy system, which front end can 
be used in design and subsequently embedded. Programs developed 
m an object oriented environment are converted intoinstructions 
iinplcmentable by a procedurally based processing device. An 
activity hierarchy of functions is created for each object, a data 
subject area is created for each object and a main calling program 
specifies the relationship between the prograins and data areas so as 
to retain the encapsulation of the original object oriented definition. 
This aspect of the invention is particularly useful for developing 
new systems in an object oriented environment which may then be 
embedded into existing procedurally based systems. 
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A DATA PROCESSING SYSTEM FOR USE IN CQMMUNICATIQMS PRICING AMD 
CHARGING EQUIPMENT AND A PRODUCTION PROCESS THEREFOR 

The present invention relates to a data processing system for use in 
pricing and charging equipment and a production process therefor. 

The data processing system finds particular application in communications 
systems, for identifying and/or adjusting amounts billed to a customer, based on 
charge-related values such as call duration, in respect of additional factors such as 
taxes which are liable to be subject to change. It is becoming increasingly 
important, particularly in the communications arena as communications systems 
grow ever more sophisticated, that factors involved in calculating billable amounts 
can be both taken into account and updated even in complex billing systems which 
have to handle a wide variety of events and conditions. 

The production process mentioned above provides a method of converting 
programs developed in an object oriented environment into instructions 
implementable by a procedurally based processing device. 

Traditionally, large data processing systems were developed using 
procedural languages, such as COBOL and FORTRAN etc. Some of these systems 
are extremely large and are responsible for fundamental operational requirements 
of organisations, often essential to the core business of said operations. 
Consequently, great care must be taken when such systems are modified. 
Furthermore, given the level of investment made in such systems, it is not 
practical to redevelop a whole system when modifications are required. 

Large systems of this type, often developed using techniques which have 
been superseded by improved development techniques, are often referred to as 
"legacy" systems or "heritage" systems, in which, were the system to be 
produced today, different techniques would be employed so as to improve 
reliability, robustness and the ability to implement amendments as changes in 
operating conditions occur. However, given that these existing systems often 
relate to very important aspects of an operation and represent a very large 
investment made by the operator, there is clearly a reluctance to make 
modifications unless these become absolutely necessary. 
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Unfortunately, from an operator's point of view, modifications do become 
necessary, due to essential changes to the way in which the operation is 
performed, possibly driven by changes in the laws or rules etc., under which the 
operation is performed. Under these circumstances, it is therefore necessary to 
5 Implement changes to existing systems. However, such changes need to be 
implemented without affecting the rest of the system, thereby ensuring that the 
operation continues to function as a whole, secure in the knowledge that other 
aspects of the system will not be impaired by the new amendments. 



10 must be consistent with the original instruction set, which suggests that 
modifications must be implemented using the techniques available when the 
system was originally developed. This would therefore result in developers being 
constrained to use old fashioned techniques instead of being able to make use of 
modern developments. Furthermore, newly trained system developers would tend 

15 to be more familiar with modern techniques, therefore, if forced to use previous 
techniques, such designers would not benefit from their more modern skill, 
experience and expertise. 

Object oriented environments are known, an example of which is that 
provided by the Al International Corporation and licensed under the Trade Mark 

20 "Visual works' which includes the language "Smalltalk 80". In an object oriented 
environment, data is encapsulated in functionality to provide units of software 
known as objects. The data is then not directly accessible to entities external to 
the object. The object oriented environment is developed by defining these objects 
and defining the communications between them. Procedural environments in 

25 contrast provide separate files for instructions and data. The transformation of 
object instructions into procedural instructions therefore consists of, amongst 
other things, collecting instructions from objects and collecting data from objects 
and grouping these collections into files which may be implemented within the 
procedural environment of the existing system. 

30 According to a first aspect of the present invention, there is provided a 

data processing system, for use in pricing and charging equipment, to process data 
which has an associated set of modifying factors, by selecting and applying 
appropriately one or more of said modifying factors, the system comprising: 



A further problem arises in that new instructions for the existing system 



)9527255 ffi(e:///C:/Documents%20an d%20Settin3^r<lan/Desktop/WO95 27255.c pc] 



Page 6 of 61 



WO 95/27255 PCT/GB95/00732 

4 

i) a data input, for data relating to one or more chargeable event(s) and 
containing for each event at least one charge-related value, such as duration, and 
at least one piece of additional data, such as event date; 

ii) a process control module for controlling processing of said data; 

5 iii) a first data store holding a set of definitions and a set of identifiers for said 
definitions, each definition including, directly or indirectly, at least one of said 
modifying factors and, associated with each modifying factor, at least one 
condition such as date of validity; and 

iv) a second data store arranged in sections allocated to respective modifying 
10 factors, 

. wherein, on receipt of data at the input, the process control module ensures that 
the system determines a relevant identifier, accesses the first data store and 
locates the relevant definition for that identifier, sorts the data according to 
modifying factor, using said additional data and the relevant definition, and outputs 

15 the charge-related values from the data to the sections of the second data store, 
whereafter the system applies the allocated modifying factor(s) to the contents of 
the sections and outputs billable values thus generated. 

Generally the system will be operating in a broader environment, such as 
the billing and charging environment of a communications system, and, although 

20 the relevant identifier may be presented to the system in a number of ways, in the 
broader environment it will already be associated with incoming data. 

A data processing system according to the first aspect of the present 
invention provides a very flexible arrangement in terms of changes in modifying 
factors. In particular, it allows charges arising before and after a change in tax 

25 regime to be billed appropriately, even if the bill itself is only to be compiled at a 
later date. For instance, if there is a change in relevant tax rates on a particular 
communications service, it is possible to accommodate that change, even if billing 
in arrears, by updating the definitions. In this case, the identifiers might each 
identify a tax category and the definitions would set out dates on which that tax 

30 category was valid or on which the rate of taxation for that category changed. A 
new class of tax can also be taken into account simply by adding a new identifier 
and definition. 
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Alternatively, the identifiers may identify a product or service and the 
definitions then might set out relevant tax categories for the products or services, 
and the date or dates on which the tax categories were or are effective. Again 
alternatively, the identifiers may identify a class of user and the definitions set out 
5 tax categories, and relevant dates of validity, for the classes of user. 

The first data store may of course be divided to accommodate more than 
one type of sets of identifiers and definitions, to be called upon appropriately by 
the data processing system, and this aspect gives the system particular flexibillity. 

Using an object-oriented environment, whether or not in combination with 
10 a different type of environment, an embodiment of the present invention could be 
described as a process for generating billable amounts in respect of data records 
for the supply of goods or services over a period of time, characterised by: 

a period charge interface object, which provides control functionality for 
use by the process in relation to charges incurred by a user over a period of time ; 
15 a tax table object, defining tax rates and callable by said period charge 

interface object; 

a tax calculation object for calculating tax values in respect of said supply 
of goods or services, callable by the period charge interface object; and 

an accumulation object, for accumulating values returned to the period 

20 charge object from the tax calculation object, 

wherein, in use, input data including a period start date and a period end date are 
supplied to the period charge interface object, tax rates are supplied to the period 
charge interface object from the tax table object, a tax calculation is made by the 
tax calculation object, and resulting calculated tax values are supplied to the 

25 accumulation object. 

It is possible to determine the functionality of an object by assigning it a 
set of alternative policies. The policies each may for instiance set out a different 
algorithm which the object will apply. Part of the functionality of the object is to 
offer a user, or some other source of input, a choice between the policies. This is 

30 a particularly useful approach to use in embodiments of the present invention to 
achieve different outputs from the system. It also allows different options to be 
built into the system at a later date, for instance by loading different types of table 
and updating the policies in the relevant object providing control functionality. 
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According to a second aspect of the present invention, there is provided a 
method of converting programs developed in an object oriented environment into 
instructions implementable by a procedurally based processing device, 
characterised by: 

creating an activity hierarchy of functions for each OT said objects; 

creating a data subject area for each of said objects; and 

defining a matrix of processes against data entities arranged to specify the 
relationship between the object derived programs and the object derived data 
subject areas to thereby retain the encapsulation defined by the object oriented 
program. 

The invention will now be described by way of example only, with 
reference to the accompanying drawings, in which: 

Figure 1 schematically represents customer terminal equipment connected 
to interconnected local exchanges and a central charging station; 

Figure 2 details processing equipment provided at the charging station 
illustrated in Figure 1, including a processor; 

Figure 3 identifies an overall procedure for modifying an existing 
procedural system, in accordance with the present invention, comprising a step of 
defining a system in an object oriented environment, a step of validating the 
system defined in said environment, and a step of converting the object oriented 
system into a procedural language. 

Figure 4 details an overview of an object oriented system defined in 
accordance with the procedure identified in Figure 3; 

Figure 5 details part of the system shown in Figure 4; 

Figure 6 details part of the system shown in Figure 4; 

Figure 7 details part of the system shown in Figure 4; 

Figure 8 details part of the system shown in Figure 4; 

Figure 9 details part of the system shown in Figure 4; 

Figure 10 details the function for calculating VAT rates given to VAT 
exclusive amounts; 

Figure 11 is an expansion of the procedure shown in Figure 10; 

Figure 12 details the procedure for calculating a rate determined at the end 
of a charging period; 
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Figure 13 details the procedure when the rate is apportioned over a period; 

Figure 14 details the procedure when a charge is made on the basis most 
favourable to a customer; and 

Figure 15A and Figure 15B detail the procedure identified at step 34 of 
Figure 3, for converting the objects oriented code into the form of a procedural 
language. 

A schematic representation of customer terminal equipment 1 5 connected 
to local exchange 16 is illustrated in Figure 1. Each local exchange includes 
storage means 17 for collecting data relating to calls made by customers 15 
connected to the associated local exchange 16. 

If a customer initiates a call using terminal equipment 1 5A to call terminal 
equipment 15B, data is logged in the storage means 17 of local exchange 16 
identifying the telephone number of the customer equipment 15B. In addition, 
information may also be stored concerning the charge band for customer 
equipment 158, such as local, long distance or international etc. Furthermore, 
data is stored which identifies the way in which the call was made which, for 
example, may state that the call was made by the telephone number for terminal 
equipment 158 being dialled directly on terminal equipment 15A. Alternatively, 
the call could have been instigated with intervention from a manual operator 
which, usually, would result in a higher rate of charge for the caller 1 5A. It is also 
possible that, although terminal equipment 15A is being used to make the call, it is 
being made by a customer who is actually signed up for terminal equipment 1 5C 
and, using charge card facilities, the cost of the charge is re-directed to the 
account associated with terminal equipment 15C, rather than the account 
associated with terminal equipment 15A. 

Telephone bills are usually despatched to customers on a quarterly basis 
and the trend has been towards the despatching of bills from a central charging 
office, rather than from each individual local exchange or regional exchange etc. 
The advantage of despatching bills from a central office is that, particularly with 
sophisticated systems which facilitate the use of charge cards etc, it is possible to 
obtain information from a plurality of sources and bring it together for inclusion on 
a single customer's bill. It is clearly advantageous from both the customers point 
of view and from the network providers point of view, given that it is unnecessary 
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to generate more than one account, with sophisticated services being added to 
conventional services and presented to the customer on a single account. 

Thus, a central charging station 18 routinely polls each of the local 
exchanges 16 to obtain stored information relating to usage made by particular 
5 customers. For the purpose of this example, it will be assumed that the time has 
come f or the central charging station 18 to generate a customer's account for the 
customer associated with the terminal equipment 15A. The charging station 18 
may have already been supplied with some of the information it requires, such as 
use of charge cards from other stations etc. It is now required to make a more 
10 conventional investigation as to the normal-type telephone calls made using 
terminal equipment 15a. Thus, the charging station 18 "polls" storage device 17 
at the local exchange 16 associated with the terminal equipment 15a, In response 
to a polling signal, storage device 17 supplies the data stored therein relating to 
terminal equipment 1 5A to the central charging station 18. 
15 Clearly, it is essential from the network provider's point of view that 

sophisticated handshaking and security provisions are made when this information 
is transferred and many references are available as to how this should be 
executed. However, suffice to say, for the purposes of the present disclosure, all 
of the relevant information is transferred from storage device 17 and the device 17 
20 is effectively cleared so that it may start afresh recording new usage made using 
terminal equipment 1 5A, as part of the next charging period. 

The charging station 18 includes a plurality of large mainframe computers. 
Given the centralised nature of the system, the programs running on said 
computers are extremely large, therefore although it is desirable or necessary to 
25 make modifications from time to time to the existing system, extreme caution 
must be employed to ensure that the overall operation of the system is maintained. 

The present embodiment provides mechanisms by which modifications to 
the existing procedural system at the central charging station 18 may be 
implemented within an object oriented environment, thereby facilitating system 
30 creation, system validation and system modification, before processing this 
information to produce instructions executable on the existing system. 

One of the functions performed by the central charging station 1 8 is the 
calculation of value added tax (VAT). Previously systems were programmed in 
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accordance with whatever VAT rules were appropriate at the time. Clearly, when 
modifications were made to the way in which VAT is calculated, such as Increases 
in the rate of VAT, the type of products to which VAT applied and the specific 
way in which the VAT was calculated, it was necessary to reformulate instructions 
5 compatible with the existing system. The present embodiment allows instructions 
relating to the generation of VAT amounts to be determined within an object 
oriented environment and thereafter incorporated into the existing system. 

The central charging station 18 shown in Figure 1 is detailed in Figure 2. 
The system includes a central processor 21, arranged to receive data relating to 

10 customer usage from a main storage device 22, in addition to receiving related 
data from a storage device 23. The processor 21 is also arranged to supply data 
to and receive data from an archive storage area 24 and, fundamentally, the 
processor 21 is arranged to supply print data to accounts printing devices 25 
which in turn produce paper accounts for customers. 

15 Non-conventional customer usage information is supplied to the main data 

storage area 22 from remote storage area 26, arranged to receive details of charge 
card usage and of other sophisticated charging usage. Conventional charging 
usage, as previously described, is received from storage device 17 at the local 
exchanges via a polling device 27, arranged to contact each of the local 

20 exchanges, possibly using facilities provided within the network itself and to 
receive data therefrom relating to usage for particular customers. Thus, under the 
control of the main co-ordinating processor, not shown, it is determined that a 
statement of account is to be produced for a particular customer, resulting in data 
associated with that customer, in the form of the numbers called, duration of call 

25 and means by which the call was initiated, being collected in a main data storage 
area 22. 

In response to program control, processor 21 is arranged to analyse the 
data stored in a main data storage area 22 and provide data which in turn may be 
supplied to the account printing device 25. Thus, it will be appreciated, that, in 
30 addition to calculating the actual charge for the services provided, the processor 
21 must also be capable of accurately calculating VAT, in order that said VAT 
amounts appear on the printed statement of account. 
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The calculation of VAT in the United Kingdom is a good example of a 
procedure which may require modification. Furthermore, during initial development 
work, it is difficult to anticipate all of the variations which may come in the not too 
distant future. However, if these variations are anticipated, measures may be 
5 taken to facilitate adjustment after the code has been embedded within the 
existing system. For this reason, it is appropriate to develop the code within an 
environment which facilitates validation exercises, allowing system designers to 
test possibilities and, as far as possible, anticipate future requirements. 

The overall procedure for modifying an existing procedural system is 

10 shown in Figure 3. At step 31 a new sub-system is defined in an object oriented 
environment. At step 31 the subsystem developed in the object oriented 
environment is validated. The validation exercise involves performing operations in 
a similar fashion to that in which they would be performed within the fully 
operational system. Thus, whereas, in the operational system information is sup 

15 plied automatically from on-line sources, during the validation exercise at step 32, 
information may be supplied manually by means of a keyboard etc. The validation 
exercise allows operators to check that the procedures are being performed in the 
desired manner. Furthermore, it also provides an environment where new ideas 
may be tested and experience has shown that the development and anticipation of 

20 new procedures is very much an interactive procedure. Thus, given an off-- line 
system upon which validation may be performed, an opportunity is provided for 
designers and operators to anticipate future demands and to thereby incorporate 
these options into the system. 

Thus, a question is asked at step 33 as to whether all the design 

25 requirements have been met. However it should be understood that these design 
requirements include original design requirements, .incorporated into the original 
system designed and implemented at step 31, in addition to new design 
requirements which may have been established during the validation procedure 
performed at step 32. If the question asked at step 33 is answered in the 

30 negative, the system is re-designed at step 31 and a validation exercise is 
executed again at step 32. 

Eventually, the question asked at step 33 will be answered in the 
affirmative, whereafter a conversion procedure is implemented at step 34 to 
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convert the instructions developed within the object oriented environment into a 
procedural language. Thereafter, at step 35, the procedural language developed at 
step 34 is embedded into the existing system, thereby allowing said system to 
operate in its updated form at step 36. 
5 The VAT processor is defined within an object oriented environment, in 

which the communication between objects is represented by the diagram shown in 
Figure 4. The object oriented environment consists of a VAT TABLE object 41 
which in turn communicates with a TABLE MANAGER object 42. Further objects 
which communicate with the VAT TABLE object 41 are a RE-VAT object 43, a DE- 

10 VAT object 44, a PERIOD CHARGE VAT REFUND object 45, a PERIOD CHARGE 
object 46 and a SINGLE DATE CHARGE object 47. Furthermore, queries are made 
to the VAT TABLE by means of a VALIDATE object 48. 

The accumulation of VAT amounts are made by means of an 
ACCUMULATOR object 49 and the ACCUMULATOR object 49 interfaces with 

15 external commands via an ACCUMULATE object 50. The ACCUMULATE object 
50 also communicates with a BASIC VAT CALCULATION object 51, which in tum 
also communicates with the DE-VAT object 44, the RE-VAT object 43, the PERIOD 
CHARGE VAT REFUND object 45 and the PERIOD CHARGE object 46. 
Calculations made by the BASIC VAT CALCULATION object 51 may require 

20 rounding, therefore the object communicates with a ROUNDER object 52. 

The ACCUMULATOR object 49 communicates with the PERIOD CHARGE 
object 46 and the SINGLE DATE CHARGE object 47. The PERIOD CHARGE VAT 
REFUND object 45 communicates with the RE-VAT object 43 and the PERIOD 
CHARGE object 46, in addition to communicating with the BASIC VAT 

25 CALCULATION object 51. A CONFIGURATION MANAGER object 53 
communicates with the ROUNDER object 52, the PERIOD CHARGE object 46 and 
the SINGLE DATE CHARGE object 47. 

Many of the objects communicate with an operator, which are referred to 
as external type objects, including the CONFIGURATION MANAGER object 53, the 

30 TABLE MANAGER object 42, the VALIDATE object 48, the DE-VAT object 44, the 
RE-VAT object 43, the ACCUMULATE object 50, the PERIOD CHARGE VAT 
REFUND object 45, the PERIOD CHARGE object 46 and the SINGLE DATE 
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CHARGE object 47. Note, different operators would access different interfaces 

when performing different functions. 

Thus, within the object oriented environment, a distinction is made 

between interfacing external objects and internal objects, when embedded within 
5 the existing procedural system, interfacing external objects will provide interfaces 

to other modules within the system, which may wish to use the services of the 

processor detailed in Figure 4. Internal objects support the interface objects and 

maintain the main attributes of the VAT processor, that is to say, the. VAT table, 

the product table, the customer table, the pair table and the accumulator table. In 
10 addition, the internal objects also provide the interface objects with the required 

processing capacity for accumulating charges, calculating VAT charges and 

performing VAT validation. 

Thus, the outer ring 54 shown in Figure 4 models the VAT processor. The 

circles model the objects contained within it; interface objects are connected to the 
1 5 outer ring 54, internal objects are only connected to other objects and an arrow is 

drawn from one object to another when an object accesses another in order to 

perform a particular task. 

The VAT processor maintains five tables, the VAT table, the product table, 

the customer table, the pair table and the accumulator table. The first four tables 
20 are maintained in the VAT TABLE internal object, while the accumulator table is 

held by the ACCUMULATOR internal object. 

The VAT table lists all existing VAT categories together with the rates that 

apply to them on the first date for which they were valid, along with any 

subsequent changes to their rates. For each category a list is maintained of 
25 associations, listing the initial date and the rate and any subsequent dates on 

which their rate is changed, with a new rate that applies from those dates. These 

elements are placed in such a list in date order. An example of a VAT table is as 

follows: 



s 


< (1/1/91,15), (1/4/91,17 5) > 


p 


< (1/1/91,0), (1/4/91,15) > 


M 


< (1/1/91,0), (1/3/92,10) > 


U 


< (1/1/91,6) > 
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This table contains four VAT categories, identified as S, P, M and U. The 
first element of the list associated with a VAT category indicates when that VAT 
category was first valid. For example, VAT category S was valid from 01 January 
5 1991, when the VAT rate at that date was fifteen percent. The next element of 
the list for category S indicates that the VAT rate applicable to category S was 
changed to seventeen point five percent on 01 April 1991. Hence, the rate of 
fifteen percent applied to S on any date from 01 January 1991 up to and including 
31 March 1991. 

10 It is possible to add a new VAT category, resulting in a new element being 

. added to the VAT table. This element contains the name of the new category and 
a list of associations (date followed by the rate). 

Procedures are implemented within the system to check whether a 
particular VAT category is valid. A VAT category is valid on a particular date if a 

15 VAT category is used in the VAT table and if a valid rate is associated with the 
entry. For example, VAT category P may be considered as being valid on 01 
January 1991 but said category was not valid on 31 December 1990. A VAT 
category is valid over a given period if it is used in the VAT table and if a valid rate 
is associated with a VAT category for each date covered by this period. Periods 

20 are described by their start date and end date and a VAT category is valid over a 
period if it is valid for each date of said period from its start date and is included up 
to its end date. 

The product table, customer table and pair table relate to product codes, 
customer classifications and their combinations to VAT categories and the dates 

25 from which these VAT categories apply. These three tables are organised to hold 
a series of keys and they link each of these keys a list of associations identifying 
the date and VAT category. The keys used in the product table are product codes 
and the keys used in the customer table are custorher classifications, whereas the 
keys used in the pair table are combinations of product codes and customer 

30 classification. 

For each key, the tables will maintain a list of associations (identifying 
date and VAT category) listing the first date on which the key was valid and the 
VAT category that applied from that date, followed by any subsequent dates on 
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Which the associated VAT category changed, with a new category that applied 
from those dates. The elements in the list are in date order. 

The product table, customer table and pair table are similar in style and 
only differ in the type of keys that are used. They are interpreted and changed in 
5 similar ways and the entries may be used to perform validation checks. An 
example of a product table is as follows: 



phone 


< (1/1/93,S) > 


fax 


< (1/1/93,5) > 


pager 


< (1/5/93,8), {1/7/93.P) > 



The first element of the list associated with a product code identifies when 
that product was first valid. For example,' product code "phone" was valid from 
01 January 1993. The VAT category that applied to product "phone" on that date 
15 was S. Product code "pager" was first valid on 01 May 1993 under VAT category 
S. The next element of the list for "pager" indicates that the VAT category 
applicable to "pager" was changed to P on 01 July 1993. Hence, the category S 
applied to pagers on any date from 01 May 1993 up to and including 30 June 
1993. 

20 An example of a customer table is as follows: 



OAP 


< (1/1/93,S) > 


business 


< (1/4/93,P) > 



25 This table contains two customer classifications, namely "Old Age 

Pensioner" and "Business". It is interpreted like the product table identified above, 
that is to say, the first element of the list associated with a customer classification 
identifies when that product was first valid. Subsequent elements list changes to 
the applicable VAT category and the dates on which those changes took effect. 

30 An example of a pair table is as follows: 



phone X OAP 



< (1/1/93,S) > 
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phone X business < (1/7/93, U) > 



It is interpreted in a substantially similar way to the product table identified 

above. 

5 The ACCUMULATOR object holds the accumulation of single date charges 

and period charges. Each information item consists of a VAT rate and a VAT 
exclusive amount and the accumulator table holds the information items. 
The following table is an example of an accumulator table: 



VAT rate 


excl. amount 


15.00 


87.72 


17.50 


199.83 


00.00 


6.5.00 



15 In order to accumulate a VAT exclusive amount, it is added to the VAT 

exclusive amount of the information item in the accumulated table and is 
associated with a rate that applies to the given amount. If no such information 
item exists in the accumulated table, a new information item is added to the table. 
This item associates the VAT exclusive amount that is to be accumulated with the 

20 rate that applies to it. Thus, it can be appreciated that the re — setting of the 
accumulator table effectively removes all numerical data stored therein. VAT rates 
are created as an item when they are required and thereafter VAT exclusive 
amounts are accumulated within the associated item. 

The system can be used for four distinct operations. Firstly, it can be 

25 used to perform a charging operation used to prepare a customer's bill, involving 
the working out of VAT amounts. Secondly, the system can be used to process 
receipts, from customers. Thirdly, the system can be used for a general enquiry 
made by operators when information is required concerning VAT amounts, and 
fourthly, the system is designed such that reconfigurations may be made, 

30 particularly when changes occur to the way in which VAT is calculated. 

All of the. objects detailed in Figure 4 are not necessarily employed for 
each of the above defined operations. The four operations will therefore be 
described with reference to specific drawings, In which the objects actually 
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employed within the system defined in Figure 4 are repeated in Figures 5 to 8, 
although it should be appreciated that the objects identified in Figure 5 to 8 are 
identical and form part of the structure defined in Figure 4. 

Figure 5 details the operations performed during the charging process, that 
5 is to say, when a customer's bill is being made up. 

A typical procedure for bill production for a particular customer will be for 
access to the system being provided via the ACCUMULATE object 50. 
Communication task 61 represents an operation performed by the ACCUMULATE 
object 50 so as to reset the value stored by the ACCUMULATOR object 49. 

10 Thus, input data will consist of any chargeable item for which it is 

necessary to calculate VAT before this item may be added to a bill although, it 
should be appreciated, that some items may be zero rated or exempt from VAT 
and this will be taken into account during the VAT processing procedure. 

VAT may be accumulated in two specific ways. Firstly, VAT may be 

15 incurred on a transaction which takes place at a particular point in time and is 
therefore processed as a single date charge. Alternatively, VAT is also incurred 
through services which are provided over a period of time and are therefore 
processed as a period charge. It is important to separate single date transactions 
from period charges primarily because it is possible that the VAT rate may change 

20 over the period under consideration. 

In order to calculate VAT for an item for which a transaction has occurred 
on a particular date, access is provided to the SINGLE DATE CHARGE object was 
incurred. In accordance with Policies specified within the SINGLE DATE CHARGE 
object 47, a call is made to the VAT table 41 , illustrated by task 62, which in turn 

25 returns a VAT rate to the SINGLE DATE CHARGE object 47. After receiving the 
appropriate VAT rate from the VAT TABLE object 41, the amount, exclusive of 
VAT, is supplied to the ACCUMULATOR object 49, The ACCUMULATOR object 
49 includes a plurality of accumulators, each associated with a particular VAT 
rate. Thus, the VAT exclusive amount supplied to the ACCUMULATOR object 49, 

30 via the task identified as 63, also includes an identification of the applicable VAT 
rate, such that the ACCUMULATOR object 49 accumulates the VAT exclusive 
amount in the accumulation area specified for the particular VAT amount supplied 
from the SINGLE DATE CHARGE object 47. 
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In some circumstances, it may be necessary for the SINGLE DATE 
CHARGE object 47 to make more than one call to the VAT TABLE object 41. For 
example, it may be possible to base VAT on the date on which the transaction 
occurred or, alternatively, it is possible to base VAT on the date of the bilL A 
5 further complication arises if the policy is selected in response to some other 
variable. 

The PERIOD CHARGE object 46 is similar to the SINGLE DATE CHARGE 
object 47, although it is capable of processing charges which occur over a period 
of time. The way in which period charges are actually calculated is again a matter 

10 of policy and many variations are possible. Thus, in accordance with the selected 
policy, it is possible to base VAT charges over a period on the start date, the end 
date, either of these in response to another variable or, in a more sophisticated 
er^vironment, to have VAT amounts apportioned over the period concerned. When 
the apportionment policy is in operation, it is necessary for the PERIOD CHARGE 

15 object 46 to supply a start date and an end date via a task indicated as 64 to the 
VAT TABLE object 41. The VAT TABLE object 101 is then arranged to apportion 
the VAT exclusive amount over the period concerned and to identify the VAT rate 
applicable to the apportioned amounts. Thus, the VAT exclusive amounts are then 
accumulated in the ACCUMULATOR object 49 via task 65, in accordance with the 

20 VAT rates supplied by the VAT TABLE object 41 . 

The BASIC VAT CALCULATION object 51 is essentially provided to 
calculate the final VAT amounts. However, under some situations, it may be 
necessary to calculate actual VAT amounts in order to determine which of a 
plurality of possible algorithms is to be selected. Thus, it is possible for the 

25 PERIOD CHARGE object 46 to supply data over line 66 to the BASIC VAT 
CALCULATION object 51 which in turn returns VAT amounts to the PERIOD 
CHARGE object 46, allowing it to make decisions as to which is the preferred 
algorithm. 

When all of the relevant data has been supplied to the system, an 
30 indication is made via the ACCUMULATE object 50 to the effect that the VAT 
amounts are to be calculated. The ACCUMULATE object 50 makes a call to the 
ACCUMULATOR object 49, via task line 67, effectively enquiring as to the status 
of the ACCUMULATOR object at that point in time. Thus, in response to this 
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enquiry, data accumulated in the ACCUMULATOR object 49 is supplied back to 
the ACCUMULATE object 50 which in turn supplies this information, via task 68, 
to the BASIC VAT CALCULATION object 51. Thus, in response to this data, 
supplied from the ACCUMULATE object 50, the BASIC VAT CALCULATOR object 
5 51 determines VAT amounts from the VAT exclusive amounts and the VAT rates 
stored in the ACCUMULATOR object 49. A special case arises concerning items 
which are VAT exempt or have a VAT rate of zero, to ensure that the BASIC VAT 
CALCULATION object does not multiply VAT exempt amounts by zero. Actual 
VAT amounts calculated by the BASIC VAT CALCULATOR object 51 are supplied 
10 to the ROUNDER object 52 identified as task 69, which rounds these values in 
accordance with current policy. Thus, for example, all VAT amounts generated by 
the basic VAT calculator may be truncated to a predetemiined number of decimal 
places, thus these truncated values would then be supplied back to the BASIC 
VAT CALCULATOR object 51. Thereafter, the VAT amounts are returned back to 
15 the ACCUMULATE object 50. 

Under some circumstances it may be necessary to give a customer a VAT 
refund. In particular, this occurs when a service has been paid for in advance and 
the VAT rate for that particular service has been reduced over the period 
concerned. Under these circumstances, an operator supplies data to the PERIOD 
20 CHARGE VAT REFUND object 45, which is an object configured so as to inherit all 
the functionality of the PERIOD CHARGE object 46. The first operation performed 
by the PERIOD CHARGE VAT REFUND object 45 is to calculate the value of VAT 
previously charged, by calling the RE-VAT object 43, identified as task 70. The 
data supplied to the RE-VAT object 43 comprises a VAT exclusive amount and a 
25 VAT category or a customer or service classification. The RE-VAT object 43 
makes a call to the VAT TABLE object 41 via task 71 which in turn returns the 
appropriate VAT rate for the item under consideration. This information is then 
supplied from the RE-VAT object 43 to the BASIC VAT CALCULATION object 51 
via task 72, which in turn returns the associated VAT amount. This value is then 
30 returned to the PERIOD CHARGE VAT REFUND object 45. Subject to appropriate 
policy definitions being stored within the PERIOD CHARGE VAT REFUND object 
45, a further call is made by said object 45 to the VAT TABLE object 41 via task 
73, in order to determine the VAT rate which would be charged at the present 
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time. Again, this information is then relayed to the 3ASIC VAT CALCULATION 
object 51 to return the actual VAT amount. A comparison is then made of the 
VAT which was charged with the VAT which would be charged at the present 
time and if the new value is lower than the actual value charged, details of an 
appropriate refund are returned to the operator. 

The description above relates to the generation of bills which include VAT 
amounts. The system is also configured to take account of VAT transactions 
when payments are made. In particular, it is possible for payments to be made 
without making specific reference to a particular bill. Under these circumstances, 
it is not immediately apparent as to what proportion of the bill relates to an actual 
charge and what proportion relates to VAT payable to Customs & Excise. Thus, 
under these circumstances, it is necessary to divide a total amount into the non- 
VAT amount and the VAT amount. In dealing with receipts, it is also sometimes 
necessary to calculate a VAT amount from a VAT exclusive amount. Procedures 
for implementing such actions are shown in Figure 6. If an operator has an amount 
which is inclusive of VAT and it is desired to obtain the value exclusive of VAT, an 
input is supplied to the DE-VAT object 44. A call is then made, identified by task 
81, to the VAT TABLE object 41. The DE-VAT object 104 supplies information 
identifying the tax point date and the classification, whereupon the VAT TABLE 
object 41 returns the VAT rate applicable to that transaction. This information is 
then supplied to the BASIC VAT CALCULATION object 51 via task 82. In 
response to this call, the BASIC VAT CALCULATION object 51 returns the VAT 
exclusive amount and the amount of VAT paid. These values are calculated with a 
call, where appropriate, to the ROUNDER object 52 via task 85. Thus, the DE- 
VAT object 44 has received a VAT rate from the VAT TABLE object 41, and the 
VAT exclusive rate and the VAT amount from the BASIC VAT CALCULATOR 
object 51. This information is now returned to the operator via the interface 
identified as 86. 

In addition to calculating VAT exclusive values from inclusive values, 
operators dealing with receipts can also re-calculate VAT when given a VAT 
exclusive value. The VAT exclusive value, along with details of the date of the 
transaction and the transaction type result in a call over interface 87 to the RE- 
VAT object 43. The RE-VAT object 43 makes a call, via task 83, to the VAT 
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TABLE object 41, which in turn returns the appropriate VAT rate. The RE-VAT 
Object 43 then calls the BASIC VAT CALCULATION object 51. identified by task 
84. which in turn returns the VAT amount. Thus, the RE-VAT object 43 returns 
over interface 87, the VAT rate, the VAT amount and the VAT inclusive value. 
5 In addition to generating VAT bills and processing receipts, general 

enqumes may be made to access the information stored in the VAT table as 
.llustrated in Figure 7. A VAT TABLE enquiry results in a call to the VALIDATE 
object 48 via an interface 91. In response to the enquiry made to the VALIDATE 
object 48, a call is made to the VAT TABLE object 41 and the appropriate 
10 infom^ation is returned to the VALIDATE object 48, whereafter it is relayed over 
the interface 91 to the operator. 

An advantage of the present embodiment is that it is configured such that 
amendments can be made to the way in which VAT calculations are executed. In 
particular, it is possible to update the VAT TABLE object 41. and make 

15 modifications to the ROUNDER object 52, the PERIOD CHARGE object 46 and the 
SINGLE DATE CHARGE object 47. 

As shown in Figure 8, modifications to the VAT TABLE object 41 are 
made via the TABLE MANAGER object 42. An operator is given access to the 
TABLE MANAGER object 42 via an interface 93 and updates for the VAT TABLE 

20 are thereafter supplied from the TABLE MANAGER object 42 over a link 94 to the 
VAT TABLE object 41. 

Similarly, an interface 95 to the CONFIGURATION MANAGER object 52 
facilitates modifications being made to the ROUNDER object 52 via a link 96, the 
PERIOD CHARGE object 46 via a link 97 and the SINGLE DATE CHARGE objert 47 
25 via a link 98. 

The individual objects within the object oriented environment will now be 
considered in detail. 

TABI F MAM/^(^pR 

30 The table manager 42 controls configuration operations relating the 

changing of entries in the VAT table and the product table. 

A first function performed by the table manager adds a given VAT 
category to the VAT table, with the given VAT rate to apply from the given date. 
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If the given VAT category is already used in the VAT table, an appropriate 
message is returned and the VAT table is left unchanged. 

A second function adds a given product code to the product table, with 
the given VAT category, to apply from the given date. If the given product code is 
5 already used in the product table, an appropriate message is returned and the 
product table is left unchanged. 

A third function adds a given customer classification to the product table, 
with a given VAT category to apply from the given date. If a given customer 
classification is already used in the customer table, an appropriate message is 
10 returned and the customer table is left unchanged. 

A fourth function adds the given combination of product code and 
customer classification to the pair table, with a given VAT category to apply from 
the given date. Again, if the given combination is already used in the pair table, an 
appropriate message is returned and the pair table is left unchanged. 

A fifth function changes the VAT table to indicate that the given VAT rate 
will be the new VAT rate to apply to the given VAT category from the given date. 
If the given VAT category is not used in the VAT table, an appropriate message is 
returned and the VAT table is left unchanged. 



the given date. If the given product code is not used in the product table, an 
appropriate message is returned and the product table is left unchanged. 

A seventh function changes the customer table to indicate that the given 
VAT category will be the new VAT category to apply to the given customer 
25 classification from the given date. If the given customer classification is not used 
in the customer table, an appropriate message is returned and the customer table 
is left unchanged. 

An eighth function changes the pair table to indicate that the given VAT 
category will be the new VAT category to apply to the given combination of 
30 product code and customer classification from the given date. If the given 
combination is not used in the pair table, an appropriate message is returned and 
the pair table is left unchanged. 



A sixth function changes the product table to indicate that the given VAT 
category will be the new VAT category to apply to the given product code from 
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A ninth function changes the VAT table to indicate that the given VAT 
category is no longer valid from the given date. If the given VAT category is not 
used in the VAT table, an appropriate message is returned and the VAT table is left 
unchanged. 

5 A tenth function changes the product table to indicate that the given 

product code is no longer valid from the given date. If the given product code is 
not used in the product table, an appropriate message is returned and the product 
table is left unchanged. 

An eleventh function changes the customer table to indicate that the given 
10 customer classification is no longer valid from the given date. If a customer 
. classification is not used in the customer table, an appropriate message is returned 
and the customer table is left unchanged. 

A twelfth function changes the pair table to indicate that the given 
combination of product code and customer classification are no longer valid from 
15 the given date. If the given combination is not used in the pair table, an 
appropriate message is returned and the pair table is left unchanged. 

RE-VAT 

The RE-VAT object controls operations requested by receipts when it is 
20 necessary to re-calculate a VAT amount. 

A first function calculates the VAT amount that applies to the given net 
amount on the given date for the given VAT category. This VAT amount is 
returned, together with the gross amount and the VAT rate which applies to that 
given amount. 

25 A second function calculates the VAT amount that applies to the given net 

amount on the given date for the given product code. The function returns this 
VAT amount, together with the gross amount and the VAT rate that applies to that 
amount. 

A third function calculates the VAT amount that applies to the given net 
30 amount on the given date for the given customer classification. The function 
returns this VAT amount, together with the gross amount and the VAT rate that 

applies to the given amount. 
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A fourth function calculates the VAT amount that applies to the given net 
amount on the given date for the given combination of product code and customer 
classification. The function returns this VAT amount together with the gross 
amount and the VAT rate that applies to the given amount. 

5 

DE-VAT 

This object controls operations requested by receipts concerning the 
removal of VAT amounts, referred to herein as DE-VATING. 

A first function calculates the VAT amount and the net amount that 
10 together form a given gross amount, using the given VAT category and date. The 
function returns the VAT amount and the net amount and the VAT rate that 
applies to the given amount. 

A second function calculates the VAT amount and the net amount that 
together form the given gross amount, using the given product code and date. The 
15 function returns the VAT amount and the net amount and the VAT rate that 
applies to the given amount. 

A third function calculates the VAT amount and the net amount that 
together form the given gross amount, using the given customer classification and 
date. The function returns the VAT amount and the net amount and the VAT rate 
20 that applies to the given amount. 

A fourth function calculates the VAT amount and the net amount that 
together form a given gross amount, using the given combination of product code, 
customer classification and date. The function returns the VAT amount and the 
net amount and the VAT rate that applies to the given amount. 

25 

PERIOD CHARGE VAT REFlJMn 

The PERIOD CHARGE VAT REFUND object 45 controls operations 
requested by billing operators concerned with calculating refunds applicable to 
period charges that have been paid for in advance but to which different (usually 
30 smaller) VAT amounts would apply had they been charged after the period, on the 
current bill. 

The functions available within this object first of all calculate the VAT 
amount that was originally charged. Next, the VAT amount is calculated that 
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would apply to the period charge if it had been included on the current bill. These 
two charges are compared and if the originally charged VAT amount is larger than 
the VAT amount applicable on the current bill date, the difference between the 
amounts is returned. This is the VAT refund that is applicable to this period 
5 charge. If the original VAT amount is less than the new VAT arhount, a zero is 
returned, indicating that no VAT needs to be refunded, if, however, there is no 
valid rate associated with this amount on the given original tax date, an 
appropriate message is returned instead. 

A first function calculates a VAT refund for a period charge that has been 

10 paid for in advance but which may have attracted a different (smaller) amount of 
VAT had it been charged at the rate applicable for the period of the current bill. If, 
however, there is no valid rate associated with this amount on the original tax 
date, an appropriate message is returned. 

A second function implements a similar procedure but related to a product 

15 code, while a third is related to a customer code and a fourth is related to a 
product-customer combination. 

PERinn THARPiF 

The PERIOD CHARGE object 45 controls operations requested by billing 

20 operators concerned with the accumulation of period charges. 

A first function calculates the VAT rates that apply to the given VAT 
exclusive amounts, using the given VAT category, period start date and period end 
date, following the current favour policy. The function accumulates the VAT 
exclusive amount in the accumulated table at the appropriate rates. 

25 A second function calculates the VAT rates that apply to the given VAT 

exclusive amounts, using the given product code, period start date and period end 
date following the current favour policy. The function accumulates the VAT 
exclusive amount in the accumulator table at the appropriate rates. 

This second function is detailed in Figure 10. The function is initiated at 

30 step 201 and at step 202 an input is received which identifies the VAT exclusive 
amount, the product code, the period start date and the period end date. At step 
203 a bill date is set to the current date, given that this is the date on which the 
bill is being calculated. 
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At step 204 an enquiry is made to the VAT table to check whether the 
input data received at step 202 is valid. Thus, a question is asked at step 205 as 
to whether the data was valid and if this question is answered in the negative, an 
output error is generated at step 206 and the process terminates at step 217. If 
the question asked at step 205 is answered in the affirmative, an enquiry is made 
at step 208 as to the status of the current policy, which may be answered in four 
possible ways. Firstly, the policy may set that over a period charge the VAT is 
calculated with respect to the bill date. Secondly, VAT could be calculated with 
respect to the end date of the period under consideration. Thirdly, the VAT could 
be apportioned over the period of consideration or fourthly, the VAT could be 
charged at a rate selected in response to another variable. 

Referring to Figure 11, the procedures carried out in response to the first 
selected policy, that is to say, VAT is charged with respect to the bill date, is 
initiated at step 300. At step 301 the VAT rate is obtained from the VAT table. A 
check is then made as to whether the product code is valid at the bill date. Thus, 
a question is asked at step 303 as to whether the product code is valid and if this 
question is answered in the negative the appropriate VAT amount is selected from 
the VAT table at step 304, based upon the end date. Thus, at step 305 VAT is 
calculated with reference to the rate at the end date and the process is terminated 
at step 308. 

If the question asked at step 303 is answered in the affirmative, the rate 
determined at the bill date is implemented in order to calculate the VAT amount 
whereafter the process terminates at step 308. 

Referring to Figure 12, the procedures performed in response to the 
second policy option at step 211, that is to say, that the VAT rate is that 
determined at the end of the period, is initiated at step 400. At step 401 the rate 
is obtained from the VAT table, applicable at the end of the period under 
consideration. Thereafter, the amount and rate is accumulated at step 402 and 
the process terminates at step 403, 

Referring to Figure 13, the procedures implemented in response to the 
third policy option at step 213, that is to say, the VAT rate is apportioned over the 
period, is detailed at step 500. 
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At step 501 a function (or routine) is called, which returns with a list of 
amounts and the rates which apply to them. These amounts are thereafter 
accumulated at step 502 and the process terminates at step 503. 

Referring to Figure 14, the procedures for the fourth policy option at step 
213, that is that none of the three preceding policies applies, are detailed from 
step 600. At step 601 a call is made to a function which returns a list of amounts 
and rates which apply to them. At step 602 each of the possible amounts and 
rates are supplied to the BASIC VAT CALCULATION object 51 which in turn 
returns VAT amounts. The amounts returned from the VAT CALCULATION object 
10 are summed for subsequent comparison. 

Having determined the VAT amounts applicable over a period, other means 
by Which the VAT could be calculated are determined, in order that these may be 
compared. Thus, at step 603 the VAT rate applicable at the end date is obtained 
from the VAT table, whereafter, at step 604, the rate read from said table at step 
15 603 along with the exclusive amount is supplied to the basic VAT calculation 
object to obtain the amount of VAT applicable based upon the end date. 

Step 605 initiates the calculation of VAT applicable at the bill date. At 
this step, the VAT rate applicable at the bill date is read from the VAT table and a 
question is then asked at step 606 as to whether the category is valid at the date 
20 of the bill, if this question is answered in the negative, the selected mode of billing 
.s taken from the other two options available within this procedure. Thus a 
question is asked at step 607 as to whether the sum derived a step 602 is less 
than the amount derived at step 604. If this question is answered in the negative 
meaning that the amount derived at step 604 is the smaller and is therefore the 
25 amount to be charged to the customer, an accumulation is made of the exclusive 
amount at step 608, along with an indication of the rate applicable at the end date 
Thereafter, the procedure terminates at step 609. Alternatively, if the question 
asked at step 607 is answered in the affirmative, to the effect that the sum 
derived at step 602 is less than the amount derived at step 604, the list derived at 
30 step 601 is accumulated and the procedure terminates at step 609. 

Alternatively, the question asked at step 606 may be answered in the 
affirmative, to the effect that the code identified at step 605 is valid 
Consequently, at step 61 1 the amount and rate applicable at the bill date are sent 
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to the basic VAT calculator to determine the VAT amount. Thereafter, at step 612 
a comparison is made of the sum calculated at step 602 and 'the amounts derived 
from step 61 1. 

If the question asked at step 612 is answered in the affirmative, to the 
5 effect that the amount calculated at step 602 is the smaller, the list ot values 
returned at step 601 are accumulated and control is directed to step 609. If, 
however, the question asked at step 612 is answered in the negative, control is 
directed to step 614. 

At step 614 a question is asked as to whether the amount calculated at 
10 step 604 is smaller than the values determined at step 611. If this question is 
answered in the affirmative, control is directed to step 615, whereupon the 
amount of VAT applicable at the end date is accumulated. Alternatively, if the 
question asked at step 614 Is answered in the negative, the amount applicable at 
the bill date is accumulated at step 616. After both steps 615 and 616, control is 
1 5 directed to step 609. 

SINGLE DATF CHARrfp 

The SINGLE DATE CHARGE object 47 controls requests by billing 
operators concerned with accumulating single date charges. A total of eight 

20 functions are available within the object. 

For the first four functions, a VAT exclusive amount is stored in the 
accumulator table. The given amount must be a positive or zero amount and 
relates to a debit for a single charge related to a purchase on the given charge 
date. If, however, there is no valid rate associated with this single date charge 

25 following the current favour policy, no amount is accumulated and an appropriate 
message is returned. 

if the current favour policy is to calculate VAT in relation to the date on 
which the transaction took place, the given aniount is accumulated at the VAT 
rate that applied to the charge on the given charge date. Alternatively, if the 

30 current favour policy specifies that VAT is calculated at the bill date, the amount is 
accumulated at the VAT rate applicable to the charge on the date of the current 
bilL If there is no valid rate associated with the charge on the current bill date, the 
amount is accumulated at the rate that applied. on the given charge date. 



wo 95/27255 



28 



PCT/GB95/00732 



If the current favour policy is such as to make a charge in dependence 
upon another variable the amount is accumulated on either the bill date or the 
charge date, dependent upon said variable. 

A first function calculates the VAT rate that applies to the given VAT 
5 exclusive amount, using the given VAT category and charge date, following the 
current favour policy. The function accumulates the VAT exclusive amount in the 
accumulator table at the appropriate rate. 

A second function calculates the VAT rate that applies to the given VAT 
exclusive amount, using the given product code and the charge date, following the 
10 current favour policy. The function accumulates the VAT exclusive amount in the 
accumulator table at the appropriate rate. 

A third function calculates the VAT rate that appNes to the given VAT 
exclusive amount, using the given customer classification and charge date, 
following the current favour policy. The function accumulates the VAT exclusive 
1 5 amount in the accumulator table at the appropriate rate. 

A fourth function calculates the VAT rate that applies to the given VAT 
exclusive amount, using the given combination of product code and customer 
classification and the given charge date, following the current favour policy. The 
function accumulates the VAT exclusive amount in the accumulator table at the 
20 appropriate rate. 

Functions 5 to 8 store a given VAT exclusive amount, which is a VAT 
credit, in the accumulator table. The given amount must be a negative or zero 
amount and relates to a credit for a single charge that was charged earlier on a bill 
issued on the given original bill date. If, however, there is no valid rate associated 
25 with a single date credit, following the currem favour policy, no amount is 
accumulated and an appropriate message is returned. 

Should legislation change, resulting in a change of the current favour 
policy to "charge at the date of the transaction", the function calculates the option 
which would have yielded the highest VAT amount applicable at the date of 
30 charge, had it been applied on the given original bill date. The credit is 
accumulated in the accumulator as if it were applied on the given original bill date. 

Again, should legislation change, resulting in a change of the current 
favour policy to "calculate charges in relation to the date of the bill", the given 
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amount is accumulated at the VAT rate that applied to the credit on the current bill 
date, if there is no valid rate associated with the charge on the current bill date, 
the function calculates which favour policy would have yielded the highest VAT 
amount applicable to the single date charge, had it been applied on the given 
5 original bill date. The credit is then accumulated in the accumulator following this 
policy as if it was applied on the given original bill date. 

It will be appreciated that provision is made in anticipation of changes in 
legislation and user guides would be provided to identify current acceptable modes 
of operation. 

10 The fifth function within this object calculates the VAT rate that applies to 

the given VAT exclusive amount, using the given VAT category, charge date and 
original bill date, following the current favour policy. The function accumulates the 
VAT exclusive amount in the accumulator table at the appropriate rate* 

The sixth function calculates the VAT rate that applies to the given VAT 
1 5 exclusive amount, using the given product code, charge date and original bill date, 
following the current favour policy. The function accumulates the VAT exclusive 
amount in the accumulator table at the appropriate rate. 

The seventh function calculates the VAT rate that applies to the given 
VAT exclusive amount, using the given customer classification, charge date and 
20 original bill date, following the current favour policy. The function accumulates the 
VAT exclusive amount in the accumulator table at the appropriate rate. 

The eighth function calculates the VAT rate that applies to the given VAT 
exclusive amount, using the given combination of product code and customer 
classification, the given charge date and the original bill date. Following the 
25 current favour policy, the function accumulates the VAT exclusive amount in the 
accumulated table at the appropriate rate. 

VALIDATE 

The VALIDATE object 48 controls operations requested concerning the 
30 validation of VAT categories, product codes, customer classifications and 
combinations of product codes and customer classifications. Nineteen functions 
are available within the object, eight of which are Boolean, in that they produce a 
true or false response to validation questions. 
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The first function returns true if a given VAT category exists in the VAT 
table and a valid VAT rate is assigned to this category on the given date. 

The second function returns true if a given product code exists in the 
product table and a valid VAT category is assigned to this product code on the 
5 given date and a valid VAT rate is associated with this VAT category in the VAT 
table on the given date. 

The third function returns true if a given customer classification exists in 
the customer table and a valid VAT category is assigned to this customer 
classification on the given date and a valid VAT rate is associated with this VAT 
10 category in the VAT table on the given date. 

A fourth function returns true if the given combination of product code 
and customer classification exists in the pair table and a valid VAT category is 
assigned to this combination on the given date and a valid VAT rate is associated 
with this VAT category in the VAT table on the given date. 
15 A fifth function returns trUe if the given VAT category is used in the VAT 

table, and a valid VAT rate applies to it for each date covered by the period from a 
given start date to a given end date. 

A sixth function returns true if a given product code is used in the product 
table and a valid VAT category applies to this product code for each date covered 
20 by the period from a given period start date to a given period end date and If all 
VAT categories that apply to this product code over this period have valid VAT 
rates associated therewith in the VAT table for each date of the period to which 
they apply. 

A seventh function returns true if a given customer classification is used in 
25 the customer table and a valid VAT category applies to this classification for each 
day covered by the period from a given period start date up to and including a 
given period end date and if all VAT categories that apply to this classification over 
this period have valid VAT rates associated therewith in the VAT table for each 
day of the period to which they apply. 
30 An eighth function returns true if the given combination of product code 

and customer classification is used in the pair table and a valid VAT category 
applies to this combination for each date covered by the period from a given period 
start date to a given period end date and if all VAT categories that apply to this 
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combination over tliis period have valid VAT rates associated therewith in the VAT 
table for each day of the period to which they apply. 

A ninth function returns a VAT rate that applies to a given VAT category 
on the given date according to the VAT table. If the VAT category is not used in 
5 the VAT table, appropriate message is returned. 

A tenth function returns the VAT category that applies to a given product 
code on a given date, according to the product table. If the product code is not 
used in the product table or if it is not valid on each day of the given period, an 
appropriate message is returned. 
10 An eleventh function returns the VAT category applicable to a given 

customer classification on a given date, according to the customer table. If the 
classification is not used in the customer table or if it is not valid on each day of 
the period, an appropriate message is returned. 

A twelfth function returns the VAT category applicable to a given 
15 combination of product code and customer classification on a given date, 
according to the pair table. If a combination is not used in the pair table or if it Is 
not valid on each day of the period, an appropriate message is returned. 

A thirteenth function returns the VAT rate applicable to a given product 
code on a given date according to the product table and the VAT table. If the 
20 product code is not used in the product table, an appropriate message is returned. 

A fourteenth function returns the VAT rate applicable to a given customer 
classification on a given date according to the customer table and the VAT table. 
If a classification is not used in the customer table, an appropriate message is 
returned. 

25 fifteenth function returns the VAT rate applicable to a given combination 

of product code and customer classification on a given date, according to the pair 
table and VAT table. If the combination is not used in the pair table, an 
appropriate message is returned. 

A sixteenth function returns a list of all VAT rates that are applicable to a 

30 given VAT category, according to the VAT table on one or more of the days of the 
period from a given start date to a given end date. If the given VAT category is 
not used in the VAT table, an appropriate message is returned. 
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A seventeenth function returns a list of all VAT categories applicable to a 
given product code, according to the product table, on one or more of the days of 
the period from the given period start date to a given period end date. If a given 
product code is not used in the product table, an appropriate message is returned. 

An eighteenth function returns a list of all VAT categories applicable to a 
given customer classification, according to the customer table, on one or more of 
the days of a period from a period start date to a given period end date. If the 
given customer classification is not used in the customer table, an appropriate 
message is returned, 

A nineteenth function returns a list of all VAT rates that are applicable to a 
given combination of product code and customer classification, according to the 
pair table, on one or more of the days of a period from a given period start date to 
a given period end date. If the given combination is not used in the pair table, an 
appropriate message is returned. 



15 



ACCHMlll Ajp 

The ACCUMULATE object 50 controls operations requested by billing 
operators concerned with resetting and retrieving information from maintained 
information items. 

20 A first function resets the accumulator tables. 

A second function returns a list of associations that are calculated from 
the accumulated VAT exclusive amounts and corresponding VAT rates stored in 
the accumulator table. The function also returns the VAT exclusive amount stored 
in this table to which VAT applies at zero rate and for which VAT is exempt. 



25 



30 



CONFIGURATIOM Mflf^/^rfpR 

The CONFIGURATION MANAGER object 53 controls operations requested 
by configuration operators, concerned with the changing of policies for calculating 

VAT charges. 

The first function sets the favour policy attribute for accumulating single 
date charges to a given policy selected from the bill date or the charge date etc. 

A second function returns the current value of the favour policy attribute 
used when calculating single date charges. 
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A third function sets a favour policy attribute for the accumulation of 
period charges to the new given policy, selected from bill date, end date, or 
apportion etc. 

A fourth function returns the current value of the favour policy attribute 
5 for the accumulation of period charges. 

A fifth function sets the rounding policy attribute of the ROUNDER object 
52 to a new degree of accuracy. This defines a number of decimal places after 
which truncation takes place, which must be an integer value between one and 
six. 

10 The sixth function returns the current value of the rounding policy attribute 

and the accuracy attribute of the ROUNDER object 52. 



CONVERSION FROM THE QBJFCT ORI FNTFR FMV/iq nMMPM T 

The procedure- for converting the object oriented instructions into a 

15 procedural type language are detailed in Figures 15A and 15B. 

In the present embodiment, the existing system was originally constructed 
from instructions defined by the COBOL language and instructions derived from the 
object oriented definition described above are converted into COBOL by initially 
being converted into instructions defined under the information engineering 

20 framework licensed by Texas Instruments Inc under the trade mark "lEF". Thus, 
the terminology used in the following description is derived from the terminology 
described under lEF, although, it should be appreciated that the underlying 
principles would be relevant to any suitable procedural type language. 

A program constructed under lEF is defined in terms of an activity 

25 hierarchy. The procedure is initiated at step 700 and at step 701 the root function 
for the activity hierarchy is defined. The lowest levels of the hierarchy define 
actual executable programs. However, in the present embodiment, translation 
from the object oriented environment into the procedural environment is effected 
by defining objects in terms of the activity hierarchy. Thus, at step 701 the 

30 system name is defined as the root function within the hierarchy. In this 
embodiment, therefore, the root function would be described as "VAT processor", 

A question is asked at step 702 as to whether the objects are typed, that 
is to say, whether the objects can be grouped together into clearly identifiable 
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sets. If this question is answered in the affirmative, a sub-function is added to the 
activity hierarchy identifying the particular types of functions. Alternatively, if the 
question asked at step 702 is answered in the negative, step 703 is bypassed and 
control is directed to step 704. 
5 In the present example, the functions are typed in terms of internal objects 

and external objects wherein, as previously stated, the external objects provide 
interfaces to operators. Thus, in the present example, an internal function is added 
to the hierarchy at step 703 identifying the presence of internal functions and 
external functions. 

10 Processing now continues by considering each object in tum. At step 704 

a process is defined having a name equivalent to the object name. Each object in 
the object oriented environment is provided with an object description and this 
object description is copied to the process description at step 705. 

In addition to processors being defined under the lEF, it is also necessary 

15 to define data areas. Thus, at this stage, the underlying distinction " between 
procedural instructions and object oriented instructions becomes visible, in that, 
separate groupings are made, within the procedural environment, for procedures' 
and data. The conversion from the object oriented environment into the procedural 
environment is effected by creating, for each object oriented object, a distinct 

20 process and a distinct data area which, when considered as a connected pair, 
reflect the definitions provided for that object within the object oriented 
environment. 

At step 706 processing is initiated with respect to the data area for the 
object being considered. Thus, a subject area is created, for the storage of data, 
25 which is identified by a name derived from the original object name. 

At step 707 a similar step is performed for the subject area which was 
performed for the process at step 705. Thus, the object description, defining its 
state, is copied to the subject area description. 

Thus, on the termination of step 707, a process area and a data area has 
30 been defined for the instruction specified within the particular object. 

Each object is itself defined, within the object oriented environment in 
terms of attributes and it is now necessary to reflect these attributes within the 
object process of the procedural environment. 
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The attributes of the object orien;:?a objects are defined within the lEF 
environment in terms of entities and, in accordance with lEF protocofe, entities 
also have collections of attributes. In order to distinguish between an object 
oriented Attribute and a lEF attribute, objects oriented Attributes will be specified 
5 with an A. 

At step 709 the Attributes description is copied to the entity description. 
At step 710 entity attributes are defined for each data item in the object Attribute. 

An example may be considered as follows. In the object oriented 
environment an Attribute may specify the address of a customer. This address is 
10 translated into an entity within the procedural lEF environment and each attribute 
within this environment will specify an item of data, such as a single time of that 
address. 

Within the lEF environment, entities and attributes are placed in data 
tables and in order to effect the transfer of information to and from the table, it is 

1 5 necessary to specify a key, that is to say, a relationship with a particular portion of 
the data entry and the particular location within the data table. Thus/ at step 71 1 
a key is defined for the data entity, along with volumetric information specifying 
the size of the entity within the database. 

Thus, it will be appreciated that step 710 will create a number of 

20 attributes which are considered in turn at step 712. At step 712 data types are 
defined for each of these attributes and ranges of valid values are also specified. 
Thus, a question is asked at step 713 as to whether another entity attribute is 
present and if this question is answered in the affirmative, control is returned to 
step 712, whereupon the next attribute is considered. 

25 If the question asked at step 713 is answered in the negative, a question 

is asked at step 714 as to whether another object Attribute is to be processed. If 
this question is answered in the affirmative, control is returned to step 718, 
whereupon a further entity is defined and attributes are specified within this entity. 
Eventually, all of the object Attributes will have been considered and the 

30 question asked at step 714 will be answered in the negative, resulting m control 
being directed to step 715. After ail of the object attributes have been considered 
for the particular object, resulting in provision being made for them within the 
procedural environment, the processing code is now transferred by creating an 
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elementary process at step 715. given a name reflecting the name of its originating 
object and the particular operation under consideration. 

At step 716 the operation description is copied to the process description 
and at step 715 imports and exports are defined, in terms of the nature of data 
5 transferred between particular objects. 

At step 718 a definition is made of the expected effects, to the effect as 
to whether data is created deleted or transferred thereafter, a question is asked at 
step 719 as to whether another object operationis present and if this question is 
answered in the affirmative, control is returned to step 719. Eventually, the 
10 question asked at step 719 will be answered in the negative, resulting in control 
being directed to step 720. 

The generation of code within the lEF environment will result in a create- 
read-update-delete (CRUD) matrix being created and this matrix provides the basis 
for ensuring that the encapsulation of the objects oriented environment has 
1 5 successfully been reflected in the procedural environment. 

Within an object oriented environment, encapsulation refers to the 
structure by which objects are defined effectively in isolation, encapsulated, as 
separate recognisable entities. This encapsulation is reflected within the 
procedural environment, by ensuring that Interactions between object-derived 
20 portions of the procedural code may only interact in the way specified by the 
encapsulation of the object oriented environment. Thus, at step 720 a question is 
asked as to whether there is any encapsulation violation and if this question is 
answered in the affirmative, the expected effects are re-defined so as to ensure 
correct encapsulation as defined within the object oriented environment. 
25 Alternatively, if the question asked at step 720 is answered in the negative, 
control is directed to step 722. 

Thus, after the definitions for each of the objects, in terms of their 
respective process are and data area, has successfully been encapsulated within 
the procedural environment, operations within the object have been successfully 
30 translated. It is now necessary to specify the interactions between objects, 
therefore at step 722 object collaboration is specified in terms of entries made into 
the lEF structure chart. 
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At step 723 the operations performed by each object are translated into 
an algorithnn compatible with the action diagram of the lEF environment. 

A question is asked at step 724 as to whether other operations are used, 
that is to say, whether other objects are called by the particular obi^ct under 
5 consideration. If the question is answered in the affirmative, a match is made of 
inputs and outputs between the two objects at step 725. Alternatively, if the 
question asked at step 724 is answered in the negative, control is directed to step 
726. 

At step 726 the question is asked as to whether the okqect under 
10 consideration is an interface object. If this question is answered in the 
affirmative, the exit state within the lEF environment is set to "processing started" 
at the start of the action block. Alternatively, if the question asked at step 726 is 
answered in the negative, control is directed to step 728, whereupon the exit state 
is set to "processing OK" before the end of the action block. 
15 After processing performed at step 727 or at step 728, the object from 

the object oriented environment has been fully translated within the procedural 
environment of the lEF and control is therefore directed to step 729. 

At step 729 a question is asked as to whether another object from the 
object oriented environment is to be translated into the procedural environment and 
20 if answered in the affirmative, control is returned to step 704. EventuaHy, all of 
the objects will have been translated, resulting in the question being asked at step 
729 being answered in the negative, whereupon the process terminates at step 
730. 

It should be noted that, by employing a conversion procedure such as that 
25 set out above, an object oriented environment can be used to configure and modify 
a data processing system which is otherwise built in a procedural environment. 
Hence an aspect of the present invention is the provision of a configuration 
system, for use in a billing and charging environment incorporating procedural- 
based data processing, comprising parts i) to iv) set out in Claim 1. 
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CLAIMS 



1. A data processing system, for use in pricing and charging equi^Mnent, to 
5 process data which has an associated set of modifying factors, by selecting and 
applying appropriately one or more of said modifying factors, the system 

comprising: 

i) a data input, for data relating to one or more chargeable event(s) and 
containing for each event at least one charge-related value, such as duration, and 

10 at least one piece of additional data, such as event date; 

«) a process control module for controlling processing of said data ; 
Hi) a first data store holding a set of definitions and a set of identifiers for said 
definitions, each definition including, directly or indirectly, at least one of said 
modifying factors and, associated with each modifying factor, at teast one 

1 5 condition such as date of validity; and 

iv) a second data store arranged in sections allocated to respective modifying 
factors, 

wherein, on receipt of data at the input, the process control module ensures that 
the system determines a relevant identifier, accesses the first data store and 
20 locates the relevant definition for that identifier, sorts the data according to 
modifying factor, using said additional data and the relevant definition, and outputs 
the charge-related values from the data to the sections of the second data store, 
whereafter the system applies the allocated modifying factor(s) to the contents of 
the sections and outputs billable values thus generated. 



25 



30 



2. A process for generating billable amounts in respect of data records for 
the supply of goods or services over a period of time, characterised by: 

a period charge interface object, which provides control functionality for 
use by the process in relation to charges incurred over a period of time ; 

a tax table object, defining tax rates and callable by said period charge 
interface object; 

a tax calculation object for calculating tax values in respect of said supply 
of goods or services, callable by the period charge interface, object; eihd 
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an accumulation object, for accumulating values returned to the period 
charge object from the tax calculation object, 

wherein, in use, input data including a period start date and a period end date are 
supplied to the period charge interface object, tax rates are supplied to the period 
5 charge interface object from the tax table object, a tax calculation is made by the 
tax calculation object, and the resulting calculated tax values are supplied to the 
accumulation object. 

3, A process according to claim 2, wherein a ''rounder" object callable by 
10 said tax calculation object is arranged to round values calculated by said tax 

calculation object. 

4, A process according to claim 3, wherein a "configuration" object is 
arranged to facilitate programming of said rounder object. 

15 

5, A process according to any of claims 2 to 4, wherein a "table manager" 
object is arranged to supply values to the tax table object and to select operational 
policy options. 

20 6. A process according to claim 5, wherein the calculation of tax at the bill 
date is a selectable option. 

7. A process according to claim 5, wherein the calculation of tax at the end 
of the usage date is a selectable option. 

25 

8. A process according to claim 5, wherein tha apportionment of tax over the 
usage period is a selectable option. 

9. A process according to any of claims 2 to 8, including a "single date 
30 charge" object for calculating tax for a transaction occurring at a specific date, 

wherein said single date charge object is arranged to call the tax table object and 
the accumulation object. 
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10. A process according to any of claims 2 to 9, including a "tax refund- 
object arranged to call said tax calculation object, the period charge object and a 
re-tax object. 



1 . Apparatus for processing data representing a supply of goods or services 
over a period of time to calculate tax associated with said supply, comprising 
processing means facilitating execution within an object orientated environment 

Characterised by the provision of: 

a "period charge" interface object; 

a "tax table" object defining tax rates and callable by the period charge 
interface object; 



10 



a tax calculation object for calculating tax for individual items, callable by 
the period charge interface object; and 

an "accumulation" object for accumulating values returned to the period 
1 5 charge object from said tax calculation object, wherein 

input data including a period start date and a period end date are supplied 

to the period charge interface object, 

tax rates are supplied to the period charge object from the tax table 

object, 

20 the tax calculation is made by the tax calculation object, and 

calculated tax value is supplied to the accumulation object. 

12. A method of converting programs developed under an object oriented 
env.ronment into instructions imp.ementable by a procedurally based processing 

25 device, characterised by; 

creating an activity hierarchy of functions (715-718) for each of said 

objects; 

creating a data subject area (704-707) for each of said objects; and 
defining a matrix of processes against data entities (722) arranged to 
30 specify the relationship between the object derived programs and the object 
denved data subject areas to thereby retain the encapsulation defined by the 

object oriented program. 
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13. A method according to claim 1 2, wherein said step of creating a data area 
includes defining a process (704) for each object. 

14. A method according to claim 12 or claim 13, wherein said data, area 
5 creation step includes copying object descriptions to respective process 

descriptions. 



15. A method according to any of claims 12 to 14, wherein said step of 
creating a procedural program includes creating an elementary process (715) 

10 derived from an object and from an operation. 

16. A method according to any of claims 12 to 15, wherein said activity 
hierarchy creation step includes defining import and export values. 

15 17. A method according to any of claims 12 to 16, including checks for 
encapsulation violation. 

18. A method of calculating taxes defined in an object oriented environment 
and converted into a procedural program by a method according to any of claims 

20 1 2 to 1 7. 

19. A method according to claim 18, wherein said object oriented definition 
includes: 

a "period charge" inteiiace object; 
2^ 3 "tax table" object defining tax rates and callable by said period charge 

interface object; 

a tax calculation object for calculating tax for individual items, callable by 
the period charge interface object; and 

an "accumulation" object for accumulating values returned to the period 
30 charge object from said tax calculation object, wherein input data including a 
period start date and a period end date are supplied to the period charge interface 
object, 
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tax rates are supplied to the period charge object from the tax table 

object, 

a tax calculation is made by the tax calculation object, and 
the calculated tax value is supplied to the accumulation object. 

5 

20. A process according to claim 19, wherein a "rounder" object callable by 
said tax calculation object, is arranged to round values calculated by said tax 

calculation object. 

10 21. A process according to claim 19, wherein a "configuration" object Is 
arranged to facilitate programming of said rounder object. 

22. A configuration management system, for use in configuring pricing and 
charging equipment for processing data which has an associated set of modifying 
15 factors, by selecting and applying appropriately one or more of said modifying 
factors, the system comprising: 

i) a data input, for data relating to one or more chargeable event(s) and 

containing for each event at least one charge-related value, such as duration, and 
at least one piece of additional data, such as event date; 
20 ii) a process control module for controlling processing of said data ; 

iii) a first data store holding a set of definitions and a set of identifiers for said 
definitions, each definition including, directly or indirectly, at least one of said 
modifying factors and, associated with each modifying factor, at least one 
condition such as date of validity; and 

25 iv) a second data store arranged in sections allocated to respective modifying 

factors, 

wherein, on receipt of data at the input, the process control module ensures that 
the system determines a relevant identifier, accesses the first data store and 
locates the relevant definition for that identifier, sorts the data according to 
30 modifying factor, using said additional data and the relevant definition, and outputs 
the charge-related values from the data to the sections of the second data store, 
whereafter the system applies the allocated modifying factor(s) to the contents of 
the sections and outputs billable values thus generated. 
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23. A configuration management system, for configuring pricing and charging 
equipment for use in generating billable values for supply of products or services, 
wherein the system comprises: 
5 a charge interface object, which provides control functionality for use by 

the equipment in relation to charges incurred; 

a tax table object, defining tax rates and callable by said charge interface 

object; 

a tax calculation object for calculating tax values in respect of said supply 
10 of goods or services, callable by the charge interface object; and 

an accumulation object, for accumulating values returned to the charge 
interface object from the tax calculation object, 

wherein, in use of the configuration management system, input data is supplied to 
the charge interface object, tax rates are supplied to the charge interface object 
15 from the tax table object, a tax calculation is made by the tax calculation object, 
and the resulting calculated tax values are supplied to the accumulation object. 



20 



24. A configuration management system according to Claim 23, wherein the 
pricing and charging equipment is embodied at least in part in a procedurally based 
environment. 
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